Methods and systems for enhancing online payment transaction experience

ABSTRACT

Embodiments provide methods, and server systems for enhancing online payment transaction experience. A method includes receiving, by a server system associated with a payment network, a tokenization request based on selecting a payment card of a plurality of payment cards of a user from a payment application running on a user device for processing an online payment transaction using the selected payment card at a merchant payment interface on the user device. The tokenization request includes a card information of the selected payment card. The method includes facilitating generation of a digital token. The digital token includes a tokenized card information of the selected payment card. The method includes provisioning the digital token in a floating widget at the merchant payment interface on the user device. The floating widget enables the user to enter the digital token at the merchant payment interface for processing the online payment transaction.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of U.S. patent applicationSer. No. 16/984,915 (filed on Aug. 4, 2020), which claims priority toSingapore Patent Application No. 10201908025R (filed on Aug. 30, 2019),all of which are hereby incorporated by reference in their entirety.

TECHNICAL FIELD

The present disclosure relates to electronic payment transactions and,more particularly to, methods and systems for creating a floatingpayment card view for entering payment card information on a merchantinterface and thereby enhancing user experience of online paymenttransaction.

BACKGROUND

Nowadays, most users use several banking cards, such as credit cards,debit cards, prepaid cards, etc., for performing financial transactions(e.g., payment transaction). The various banking cards are hereinreferred to as payment cards. The payment cards are increasingly usedfor making payments through various channels, such as physical cardswipe at point-of-sale (POS) terminals, digital payments, contactlesspayments, etc. Digital payment industry is moving towards providingbetter user experience for both consumers and merchants. Consumersdigitize the payment cards into the mobile phones, wearable devicesetc., using technologies, such as tokenization, Card-on-File (COF)transactions, digital wallets and the like. Tokenization allows consumerto digitize his/her existing payment cards into a mobile phone or otherdevices using a token and use the token at various merchant terminals.The token may contain a 16-digit number, an expiry date and a CardVerification Value (CVV) which resemble the actual payment cardinformation. Transactions performed using tokens are more secure as theactual card information is protected against theft and misuse.

In a scenario, when a user wants to purchase a product from a merchantapplication running on his smartphone, the user may select a paymentcard based payment method at the checkout page of the application. Next,the user is asked to fill in the payment card information using a cardinformation format that includes various information fields and formfields. Examples include a card number, a name of the user, an expirydate, a CVV, etc. The user needs to enter the information using thetoken i.e., a digitized payment card for a secure payment transaction.Generally, copying of the token from the wallet application and pastingthe same on the merchant application is disabled in order to provideextra security.

Therefore, in order to fill each field, the user needs to hover betweenthe wallet application which provides the token and the merchantapplication on which the token needs to be entered, until completed. Theuser may try to remember a few digits of the token at a time from thewallet application where the token is present and enter them on thecheckout page of the merchant application. This may end up in enteringwrong digits and eventually repeat the process again. Alternatively, theuser has to copy the token information on a piece of paper and go to themerchant application for manually entering the information. This couldbe very time consuming, tedious, and generally undesirable for the user.

Accordingly, there is a need for techniques that enable the user toenter the tokenized card information on the merchant payment interfaceseamlessly and process the payment transaction securely.

SUMMARY

Various embodiments of the present disclosure provide systems, methods,electronic devices and computer program products to enhance onlinepayment transaction experience.

In an embodiment, a computer-implemented method is disclosed. The methodincludes receiving, by a server system associated with a paymentnetwork, a tokenization request based on selecting a payment card of aplurality of payment cards of a user from a payment application runningon a user device for processing an online payment transaction using theselected payment card at a merchant payment interface on the userdevice. The tokenization request at least includes a card information ofthe selected payment card. The method includes facilitating generationof a digital token. The digital token includes a tokenized cardinformation of the selected payment card. The method further includesprovisioning the digital token in a floating widget at the merchantpayment interface on the user device. The floating widget enables theuser to enter the digital token at the merchant payment interface forprocessing the online payment transaction.

In another embodiment, a server system in a payment network is provided.The server system includes a communication interface configured toreceive a tokenization request based on selecting a payment card of aplurality of payment cards of a user from a payment application runningon a user device for processing an online payment transaction using theselected payment card at a merchant payment interface on the userdevice. The tokenization request at least includes a card information ofthe selected payment card. The server system includes a memorycomprising executable instructions and a processor communicably coupledto the communication interface. The processor is configured to executethe instructions to cause the server system to at least facilitategeneration of a digital token. The digital token includes a tokenizedcard information of the selected payment card. The server system isfurther caused to provision the digital token in a floating widget atthe merchant payment interface on the user device. The floating widgetenables the user to enter the digital token at the merchant paymentinterface for processing the online payment transaction.

In yet another embodiment, a computer program product is provided. Thecomputer program product includes at least one non-transitorycomputer-readable storage medium. The computer-readable storage mediumincludes a set of instructions. The set of instructions when executed byone or more processors in an electronic device, cause the electronicdevice to at least receive a tokenization request based on selecting apayment card of a plurality of payment cards of a user for processing anonline payment transaction using the selected payment card at a merchantpayment interface. The tokenization request at least includes a cardinformation of the selected payment card. The electronic device isfurther caused to facilitate generation of a digital token. The digitaltoken includes a tokenized card information of the selected paymentcard. Moreover, the electronic device is caused to provision the digitaltoken in a floating widget at the merchant payment interface. Thefloating widget enables the user to enter the digital token at themerchant payment interface for processing the online paymenttransaction.

BRIEF DESCRIPTION OF THE FIGURES

For a more complete understanding of example embodiments of the presenttechnology, reference is now made to the following descriptions taken inconnection with the accompanying drawings in which:

FIG. 1 illustrates an example representation of an environment, relatedto at least some example embodiments of the present disclosure;

FIG. 2 represents a sequence flow diagram representing a generation of adigital token, in accordance with an example embodiment;

FIG. 3A represents a sequence flow diagram representing a completion ofa payment transaction using the digital token in a floating widget, inaccordance with an example embodiment;

FIG. 3B represents a flow diagram of a method for completing a paymenttransaction using the digital token in the floating widget, inaccordance with another example embodiment;

FIGS. 4A to 4G represents an example representation of an online paymentprocess flow using the digital token in the floating widget displayed ata merchant payment interface on the user device with corresponding UserInterfaces (UIs), in accordance with an example embodiment;

FIG. 5 illustrates a flow diagram of a method for enhancing onlinepayment transaction experience, in accordance with an exampleembodiment;

FIG. 6 is a simplified block diagram of a server system, in accordancewith one embodiment of the present disclosure;

FIG. 7 is a simplified block diagram of a wallet server, in accordancewith one embodiment of the present disclosure;

FIG. 8 is a simplified block diagram of an issuer server, in accordancewith one embodiment of the present disclosure;

FIG. 9 is a simplified block diagram of an acquirer server, inaccordance with one embodiment of the present disclosure;

FIG. 10 is a simplified block diagram of a payment server, in accordancewith one embodiment of the present disclosure; and

FIG. 11 shows simplified block diagram of a user device capable ofimplementing at least some embodiments of the present disclosure.

The drawings referred to in this description are not to be understood asbeing drawn to scale except if specifically noted, and such drawings areonly exemplary in nature.

DETAILED DESCRIPTION

In the following description, for purposes of explanation, numerousspecific details are set forth in order to provide a thoroughunderstanding of the present disclosure. It will be apparent, however,to one skilled in the art that the present disclosure can be practicedwithout these specific details.

Reference in this specification to “one embodiment” or “an embodiment”means that a particular feature, structure, or characteristic describedin connection with the embodiment is included in at least one embodimentof the present disclosure. The appearance of the phrase “in anembodiment” in various places in the specification are not necessarilyall referring to the same embodiment, nor are separate or alternativeembodiments mutually exclusive of other embodiments. Moreover, variousfeatures are described which may be exhibited by some embodiments andnot by others. Similarly, various requirements are described which maybe requirements for some embodiments but not for other embodiments.

Moreover, although the following description contains many specifics forthe purposes of illustration, anyone skilled in the art will appreciatethat many variations and/or alterations to said details are within thescope of the present disclosure. Similarly, although many of thefeatures of the present disclosure are described in terms of each other,or in conjunction with each other, one skilled in the art willappreciate that many of these features can be provided independently ofother features. Accordingly, this description of the present disclosureis set forth without any loss of generality to, and without imposinglimitations upon, the present disclosure.

The term “payment account” used throughout the description refer to afinancial account that is used to fund the financial transaction(interchangeably referred to as “payment transaction”). Examples of thepayment account include, but is not limited to a savings account, acredit account, a checking account and a virtual payment account. Thepayment account may be associated with an entity such as an individualperson, a family, a commercial entity, a company, a corporation, agovernmental entity, a non-profit organization and the like. In somescenarios, a payment account may be a virtual or temporary paymentaccount that can be mapped or linked to a primary payment account, suchas those accounts managed by PayPal®, and the like.

The term “payment network”, used throughout the description, refer to anetwork or collection of systems used for transfer of funds through useof cash-substitutes. Payment networks may use a variety of differentprotocols and procedures in order to process the transfer of money forvarious types of transactions. Transactions that may be performed via apayment network may include product or service purchases, creditpurchases, debit transactions, fund transfers, account withdrawals, etc.Payment networks may be configured to perform transactions viacash-substitutes, which may include payment cards, letters of credit,checks, financial accounts, etc. Examples of networks or systemsconfigured to perform as payment networks include those operated byMasterCard®, VISA®, Discover®, American Express®, etc.

The term “payment card”, used throughout the description, refers to aphysical or virtual card linked with a financial or payment account thatmay be used to fund a financial transaction to a merchant or any suchfacility via the associated payment account. Examples of the paymentcard include, but are not limited to, debit cards, credit cards, prepaidcards, virtual payment numbers, virtual card numbers, forex cards,charge cards and stored-value cards. A payment card may be a physicalcard that may be presented to the merchant for funding the payment.Alternatively, or additionally, the payment card may be embodied in formof data (e.g., a digital token) stored in a user device, where the datais associated with payment account such that the data can be used toprocess the financial transaction between the payment account and amerchant's financial account.

Overview

Various example embodiments of the present disclosure provide methods,systems, user devices and computer program products for enhancing onlinepayment transaction experience of a user by enabling usage of a floatingpayment card in a widget for entering the card details on the merchantpayment interface during the payment transaction.

In various example embodiments, the present disclosure provides a serversystem configured to receive a tokenization request generated from auser device, such as a mobile phone of a user to tokenize a payment cardlinked with the user. The tokenization request is generated using apayment application accessible on the user device as facilitated by awallet server (an example of the server system). The user may berequired to authenticate himself, for example, by providing a biometricinformation on a UI of the payment application prior to initiating thetokenization request. Examples of the wallet server include mobilebanking applications, bank wallet applications, third-party walletapplications, payment gateways or any other Internet of Things (IoT)payment devices. The tokenization request includes a card information ofthe payment card of the user. The tokenization request may also includeadditional information such as, but not limited to, a mobile number ofthe user, a payment application identifier, a primary account number ofthe user, a transaction limit and the like.

In one embodiment, the wallet server facilitates generation of a digitaltoken upon receiving the tokenization request. The wallet server sendsthe tokenization request to an interchange server (i.e. a paymentserver, an example of the server system). The payment server sends thetokenization request to an issuer server (an example of the serversystem) for authorization. The issuer server is configured to validatethe card information. The issuer server notifies the payment serverabout successful validation of the tokenization request. Thereafter, thepayment server generates a digital token for the payment card. Thedigital token includes safe and secure tokenized card information of thepayment card. In a non-limiting example, the payment server may replacethe payment card's primary account number (e.g., the 16-digit numberpresent on the physical payment card) with a unique alternate cardnumber that is called a token/digital token.

In one embodiment, the digital token is sent to the user device via thepayment application facilitated by the wallet server as received fromthe payment server. The user is enabled to use the digital token forvarious merchant payment interface such as, but not limited to, mobilepoint-of-sale transactions, in-app purchases, online purchases,contactless tap and pay transactions, and the like. For example, thedigital token can be entered at a checkout page (an example of themerchant payment interface) of a merchant e-commerce website using theuser device. In order to enable the user to effortlessly enter thedigital token on the checkout page, the payment application isconfigured to provision a floating widget that includes the digitaltoken as an image on the display screen of the user device where themerchant website is open. The size of the floating widget is minimalenough to show the details correctly. Further, the floating widget canbe moved to any corner of the display screen of the user device forentering the tokenized card information.

Furthermore, the server system is configured to facilitate display of apre-defined list of merchants for user selection on a User Interface(UI) of the payment application. The user is given option to select oneor more merchants or merchants' applications installed on the userdevice from the pre-defined list of the merchants to authorize thegeneration of the floating widget (that would include the token) for theselected merchants. Therefore, the payment application provisions arespective digital token in a corresponding floating widget only foreach of the one or more merchants selected by the user. This featureprovides added security.

In one embodiment, as the payment application already has a list ofselected merchants, when the user is at a checkout page/the merchantpayment interface of an authorized merchant's application, the userselects an option for ‘pay using a token’ on the check-out page. Theselection of paying using token option triggers tokenization of thepayment card. The merchant application communicates with the paymentapplication to request tokenization of the payment card. Without theneed of the user to visit the payment application to provide thetokenization command, the tokenized card information is displayed in afloating widget by the payment application on the check-out page of themerchant's application.

The merchant payment interface sends the digital token to an acquirerserver (an example of the server system) associated with an acquirerbank of the merchant after receiving the digital token as entered by theuser from the floating widget. The acquirer server sends the digitaltoken to the payment server for validation. The payment server validatesthe digital token and retrieves the underlying card information of thetokenized payment card for sending to the issuer server forauthorization. The payment server may also send the transaction amountto the issuer server to verify sufficient funds present in an issueraccount of the first user. Once, the payment server receivesconfirmation of authorization of the card information from the issuerserver, the payment server facilitates the payment transaction from theissuer account of the user to the merchant account.

Various example embodiments of present disclosure are describedhereinafter with reference to FIGS. 1 to 11 .

FIG. 1 illustrates an example representation of an environment 100, inwhich at least some example embodiments of the present disclosure can beimplemented. A merchant application 105 (exemplarily represented as‘e-commerce.com’) is shown running on a user device 115 (i.e., a mobilephone) of a user (not shown). Examples of the user device 115 include,but are not limited to, a personal computer (PC), a mobile phone, atablet device, a Personal Digital Assistant (PDA), a voice activatedassistant, a Virtual Reality (VR) device, a smartphone and a laptop. Acheckout page 110 (an example of the merchant payment interface foronline payment transactions) of the merchant application 105 is shownseeking payment card information of a payment card (not shown) of theuser to process a payment transaction as initiated by the user using theuser device 115.

The merchant application 105 is shown to display various form fields 112to be filled by the user such as a payment card number (e.g., xxxx xxxxxxxx xxxx where ‘x’ is an integral number) of the payment card, expirydate (e.g., MM/YYYY, month and year of expiry), Card Verification Value(CVV) number (e.g., *** where * is an integral number) and the like. Thepayment card is exemplarily represented as ‘1234 5678 0000 5678’. Theexpiry date is exemplarily represented as ‘12/2022’. The name of theuser is exemplarily represented as ‘Eva Smith’. The form fields 112 maycollectively be referred to hereinafter as a card information 112 of thepayment card. Alternatively, the card information 112 may includeinformation such as cardholder's payment account number, or anyidentification number associated with the payment card.

Various embodiments of the present disclosure provide mechanisms suchthat the user is enabled to enter the card information 112 from afloating widget 120 that includes a tokenized card information of thepayment card in the form of a digital token 125 to be entered on themerchant application 105 in order to process the payment transaction. Ina non-limiting example, the token 125 is a numeric code of variablelength (13 to 19 digits). As shown, the user has entered the cardinformation 112 as visible from the token 125 on the floating widget120. To have the token 125 in the floating widget 120, the user needs toinitiate a tokenization request from a payment application (not shown)where the payment card is linked by switching from the merchantapplication 105. For instance, the user needs to select a preferredpayment card. The underlying card information is used by the paymentapplication to generate the tokenization request of tokenizing thepayment card.

In a non-limiting example, the process of tokenization of the paymentcard and provisioning of the digital token 125 in the floating widget120 for completion of the payment transaction is facilitated by acombination of a wallet server 155, a payment server 140, an issuerserver 135 and an acquirer server 130. In one embodiment, thetokenization request is sent to the payment server 140 associated with apayment network 145. The payment network 145 may be used by the paymentcards issuing authorities as a payment interchange network. Examples ofpayment interchange network include, but not limited to, Mastercard®payment system interchange network. The Mastercard® payment systeminterchange network is a proprietary communications standard promulgatedby Mastercard International Incorporated® for the exchange of financialtransaction data between financial institutions that are members ofMastercard International Incorporated®. (Mastercard is a registeredtrademark of Mastercard International Incorporated located in Purchase,N.Y.). Further, Mastercard Digital Enablement Service (MDES) is aservice/a tokenization platform facilitated by Mastercard® paymentsystem interchange network that allows issuers, registered users, tokenrequestors and merchants to turn the payment card numbers into digitaltokens for secure digital payment transactions.

In one embodiment, the payment application is facilitated by the walletserver 155. The wallet server 155 is associated with a token requestorwhich needs to register with a token service provider (e.g., the paymentserver 140/MDES) in order to request generation of the digital tokens.Examples of token requestor include mobile banking applications, bankwallet applications, third-party wallet applications, payment gatewaysand the like. Digital wallet platforms such as Apple Pay®, Samsung Pay®,Google pay Microsoft Wallet etc., provide mobile and web applications(e.g., the payment application) using which the users can generate thetokenization request of their payment cards as well as use the generateddigital tokens (e.g., the digital token 125) for digital payments at themerchant interfaces.

In one example embodiment, the wallet server 155 may store the paymentapplication and provision instances of the application to end-users ontheir respective user devices for facilitating the token generation andthereby provisioning the digital token in the floating widget forprocessing various online payment transactions. The end-users mayrequest the wallet server 155 to provision access to the paymentapplication over a network 150. The instances of the application maythereafter be downloaded on the user devices (such as the user device115) of the respective end-users in response to their request for accessto the application. Alternatively, in some embodiments, the applicationmay be factory installed within the user devices associated with theend-users and, as such, the users may not need to explicitly request theapplication from the wallet server 155.

The issuer server 135 is associated with a financial institutionnormally called as an “issuer bank” or “issuing bank” or simply“issuer”, in which the user may have an account, which issues a paymentcard, such as a credit card or a debit card. The issuer server 135 alsofacilitates authorization of the tokenization request received from theuser device 115.

To accept payment using the digital token 125 based payment transaction,the merchant (not shown) must normally establish an account with afinancial institution that is part of the financial payment system. Thisfinancial institution is usually called the “merchant bank” or the“acquiring bank” or “acquirer bank” or simply “acquirer”. The acquirerserver 130 is associated with the acquirer bank.

Using the payment network 145, the computers of the acquirer/theacquirer server 130 or the merchant processor communicate with thecomputers of the issuer/the issuer server 135 to determine whether theuser's account is in good standing and whether the purchase is coveredby the user's available account balance. Based on these determinations,authorization of the payment transaction is declined or accepted. Whenthe authorization is accepted, the available balance of the user'saccount is decreased. Normally, a charge is not posted immediately to auser's account because bankcard associations, such as MastercardInternational Incorporated®, have promulgated rules that do not allow amerchant to charge, or “capture,” a transaction until goods are shippedor services are delivered. When the merchant ships or delivers the goodsor services, the merchant captures the transaction by, for example,appropriate data entry procedures on the point-of-sale (POS) terminal.If a user cancels a transaction before it is captured, a “void” isgenerated. If the user returns goods after the transaction has beencaptured, a “credit” is generated.

After a transaction is captured, the transaction is settled between themerchant, the acquirer and the issuer. Settlement refers to the transferof financial data or funds between the merchant's account, the acquirer,and the issuer, related to the transaction. Usually, transactions arecaptured and accumulated into a “batch”, which is settled as a group.

The user device 115, a merchant device (not shown) associated with themerchant interface (e.g., the merchant application 105), the issuerserver 135, the acquirer server 130, the wallet server 155 and thepayment server 140 communicate with one another using the network 150.Examples of the network 150 may include any type of wired network,wireless network, or a combination of wired and wireless networks. Awireless network may be a wireless local area network (“WLAN”), awireless wide area network (“WWAN”), or any other type of wirelessnetwork now known or later developed. Additionally, the network 150 maybe or include the Internet, intranets, extranets, microwave networks,satellite communications, cellular systems, personal communicationservices (“PCS”), infrared communications, global area networks, orother suitable networks, etc., or any combination of two or more suchnetworks.

Since the user already has a ready reference in the form of a floating,resizable, non-copiable, secure widget that includes the digital tokento be entered on the merchant application 105, the overall transactionflow is effortless for completing the payment transaction for the user.In existing (conventional) payment transaction methods (i.e., not inaccordance with the present disclosure), the user is either required tohover between the merchant application 105 and the payment applicationon the user device 115 continuously until the card details 112 arecompletely entered or copy the digital token 125 (hereinafteralternatively referred to as the token 125) manually on a piece of paperand later enter it again on the merchant application 105. In contrast toexisting payment transaction methods, by using the embodiments of thepresent disclosure, the user is only required to tokenize his choice ofthe payment card and a floating widget with a secure digital token ofthe same card is shown for the user to enter the details from. Hence,the user does not need to worry about remembering the token digits if hehas opted to hover between the merchant application 105 and the paymentapplication which further increases the risk of errors and therebyrepeating the whole process again. Some non-exhaustive exampleembodiments of completing online payment transactions using digitaltokens in floating widgets are described with reference to the followingdescription, particularly with reference to FIGS. 2 to FIGS. 4A to 4G.

FIG. 2 represents a sequence flow diagram 200 representing thegeneration of the token 125, in accordance with an example embodiment ofthe present disclosure. In at least one embodiment, and as explainedwith reference to FIG. 1 , when a user wants to purchase a product or aservice from a merchant interface, such as a merchant mobile applicationor a merchant website, the user is asked to enter payment card detailsat the checkout page upon selection of the cards as a preferred paymentmethod for processing the payment transaction. Therefore, the user needsto move out of the merchant application for a time being and go to thepayment application where one or more of his payment cards are linked inorder to get the card details.

At 205, a user upon accessing the website and/or a payment application(as facilitated by the wallet server 155) accessible on his user device(e.g., a user device 115), is presented with one or more UIs displayed(not shown) on a display screen of the user device 115 to send atokenization request of a payment card (linked to the paymentapplication) to the wallet server 155. As explained with reference toFIG. 1 , the tokenization request is generated by the paymentapplication based on receiving a user selection of a preferred paymentcard from a plurality of payment cards of the user linked to the paymentapplication. Further, the tokenization request includes the underlyingcard information of the selected payment card to be used for generationof a token. Additionally, the tokenization request may include amerchant name based restriction, a merchant category code basedrestriction, and the like.

At 210, the wallet server 155 sends the tokenization request to thepayment server 140 for tokenization of the payment card. At 215, thepayment server 140 sends the tokenization request to the issuer server135 for authorization. Authorization of the card information of thepayment card is performed by the issuer server 135. The authorizationprocess includes validating the card information of the payment card.Further, verification of the cardholder identification is performed bythe issuer server 135. At 220, the issuer server 135 notifies thepayment server 140 of the successful authorization of the tokenizationrequest as well as verification of the cardholder.

At 225, the payment server 140 is configured to generate a digital token(e.g., the token 125) that includes a tokenized card information of thepayment card. In an example embodiment, the payment server 140 isconfigured to generate a digital token for any funding source of theuser other than the payment card. Token values vary in format and may becryptographically or non-cryptographically generated. Further, the tokenformat may be a PAN-formatted replacement value based on a designatedtoken Bank Identification Number (BIN) or token card range. For example,the token may contain a replacement value for each of a sixteen-digitnumber, an expiry date (actually applicable for the validity of thetoken), a CVV, etc., of a physical payment card of the user so as to usesuch tokenized card information at various merchant payment interfaces.Further, a single PAN may be mapped to multiple tokens for differentscenarios. Also, in place of an account PAN of the user, a 16-digittoken may be generated such that the use of a token rather than a PANminimizes the impact of account data compromise.

If compromised or stolen, tokens reduce the likelihood of subsequentfraud since they have no value outside a specific device, merchant oracceptance channel. Further, the usage of the token can be restrictedbased on multiple criteria, such as assigning the token to a specificdevice, channel, merchant or geographic location or a combination ofthese to restrict the transaction within that domain. The generatedtokens and the original PANs they map to are stored securely in adatabase of the payment server 140 and the mapping is used during thede-tokenization process i.e., during a payment transaction. The paymentserver 140 is further configured to continually manage the token throughsuspension, deletions, updates, etc.

At 230, the payment server 140 sends the token to the wallet server 155.At 235, the wallet server 155 further sends the token to the user device115 via the payment application. The token generation process completesat operation 240.

FIG. 3A represents a sequence flow diagram 300A representing acompletion of a payment transaction using a digital token in a floatingwidget, in accordance with an example embodiment.

As explained with reference to operation 235 of FIG. 2 , the paymentapplication displays the token (e.g., the token 125) on the user device115. In at least one embodiment, upon generation of the token, thepayment application is configured to generate a floating widget thatincludes the token. The floating widget is a control element in agraphical user interface. The floating widget is also referred as apalette window or a utility window or a floating palette that floats ontop of all regular windows and offers ready access tools, commands orinformation for the current/parent application. The floating window isscaled to fit contents, it is movable, and consumes less of acomputer's/any user device's commonly landscape oriented screen space.Further, the floating widget is only visible while the parentapplication has focus.

In at least one embodiment, such floating widget that includes the tokenis displayed on the merchant payment interface (i.e., the checkout pageof the merchant application). Using the token readily available in thefloating widget, the user is enabled to enter the tokenized card detailson the merchant payment interface very conveniently by switching back tothe merchant application. In an example embodiment, the wallet server155 uses the APIs supported by the respective Operating Systems runningon the user device to generate the floating widget and display thetoken. The payment process flow carried out using the token in thefloating widget is explained in detail with corresponding UIs withreference to FIGS. 4A to 4G later.

At 305, a merchant payment interface 302 receives the token as enteredby the user from the floating widget present on the merchant applicationrunning on the user device 115. The merchant payment interface 302 canbe associated with an online merchant interface, such as a merchantwebsite, mobile or desktop applications, or third-party websites orapplications using which the consumer/user may purchase goods or servicefrom a remote location. At 310, the merchant payment interface 302 sendsthe token and a transaction amount to the acquirer server 130 forfurther processing.

At 315, the acquirer server 130 sends the token and the transactionamount to the payment server 140 for validation. The acquirer server 130also determines the acquirer account of the merchant and sends theacquirer account details to the payment server 140. At 320, the paymentserver 140 validates the token by mapping the token to its associatedcardholder PAN (i.e., PAN of the user) stored in the database. Further,the payment server 140 identifies the merchant using the acquirerdetails received from the acquirer server 130 for facilitatingcompletion of the payment transaction.

At 325, the payment server 140 retrieves the card information of thepayment card from the token through de-tokenization process. The paymentserver 140 further validates if the requested payment transaction is inline with any transaction limitations or restrictions for the use of thetoken as stored in the database of the payment server 140. If any of thevalidations fails, the payment server 140 rejects the transaction andnotifies the acquirer server 130 accordingly. In an embodiment, thepayment server 140 is configured to store the token and the associatedpayment credentials, such as the card information and the like in acloud storage.

At 330, the retrieved card information and the transaction amount aresent to the issuer server 135 for authorization. At 335, the issuerserver 135 performs authorization of the payment card and transactionamount by verifying the card information of the payment card, availablebalance amount in the cardholder account against the receivedtransaction amount, issuer account information and the like. Somenon-exhaustive examples of the issuer account information include BankIdentifier Code (BIC), account number, payment card number and the like.

At 340, the issuer server 135 notifies the payment server 140 of thesuccessful authorization of the payment card, the user and thetransaction amount. At 345, the issuer server 135 debits the transactionamount from the user's account. At 350, the issuer server 135 sends anotification of debiting of the transaction amount to the acquirerserver 130 via the payment network 145. At 355, the acquirer server 130credits the transaction amount in the merchant account. At 360, theacquirer server 130 sends the transaction status to the merchant paymentinterface 302. The transaction status may include successful, failure orpending. At 365, the issuer server 135 sends the transaction status tothe wallet server 155. At 370, the wallet server 155 sends thetransaction status to user device 115 of the user. Alternatively, thetransaction status may be sent by the merchant payment interface 302 tothe user device 115. The transaction process completes at operation 375.Once the transaction completes, the floating widget and thecorresponding token is automatically closed by the payment applicationfor security purposes. Alternatively, the user is enabled to close thefloating widget manually using a close button provided at the top cornerof the floating widget window.

Thus, a payment transaction flow using the digital token displayed inthe floating widget as explained collectively with reference to FIGS. 2and 3A provides the end consumers a better user experience as comparedto conventional techniques. Since, only the token flows through thevarious channels, it prevents misuse of the card information. Further,as the user is provided with a facility to effortlessly enter thetokenized card information from the floating widget, he is sparred fromremembering the token digits or noting them down manually on otherresources for entering on the merchant application.

FIG. 3B represents a flow diagram of a method 300B for completing apayment transaction using a digital token in a floating widget, inaccordance with another example embodiment. In one embodiment, thepayment application is configured to facilitate display of a pre-definedlist of merchants for user selection using a User Interface (UI) on theuser device (e.g., a user device 115) at the time of user registration.The user is given option to select one or more merchants on the userdevice from the pre-defined list of the merchants to authorize thegeneration of the floating widget (that would include the token) for theselected merchants. The merchant can be selected by providing merchantname, merchant application or merchant domain name.

At 302, a merchant payment interface displays a ‘pay using a token’option as a payment method for processing the payment truncation.Therefore, the user is not asked to enter payment card details at thecheckout page as he has not selected ‘cards’ as a preferred paymentmethod for processing the payment transaction. As the merchant ispre-authorized by the user via the payment application, the merchantapplication is configured to add token based payment method for aquicker user check-out experience.

At 304, the merchant payment interface receives user selection of theoption ‘pay using a token’ from the user device.

At 306, the merchant payment interface communicates with the paymentapplication for initiating the tokenization of the payment cardpre-linked to the merchant. Therefore, the user does not need to moveout of the merchant application for a time being and go to the paymentapplication where one or more of his payment cards are linked in orderto get the card details or to provide the tokenization command of thepayment card.

At 308, the merchant payment interface receives the token in a floatingwidget from the payment application for displaying on the user device.The method ends at step 308. Using the token readily available in thefloating widget, the user is enabled to enter the tokenized card detailson the merchant payment interface very conveniently without switchingbetween the merchant application and the payment application. In oneembodiment, as the merchant application receives the token as entered bythe user, the token is sent to the acquirer server 130. The steps315-375 are processed as explained with reference to FIG. 3A forcompleting the payment transaction.

FIGS. 4A to 4G represents an example representation of an online paymentprocess flow using a digital token in the floating widget displayed at amerchant payment interface on the user device with corresponding UserInterfaces (UIs), in accordance with an example embodiment.

As shown in FIG. 4A, a merchant application 405 (e.g., eshop.com 405) isconfigured to display a UI 410 enlisting a number of payment methods foruser selection to process a payment transaction on a user device 415(e.g., a smartphone 415). A header 412 displaying text ‘select a paymentmethod’ is accompanied by a plurality of payment methods 414(hereinafter alternatively referred to as payment methods 414)exemplarily displayed as ‘cards’, ‘net banking’, and ‘wallets’. The UI410 displays a user selection of the payment method ‘cards’. In analternate embodiment, the user may first select ‘wallets’ as a preferredpayment method and then may be directed to a UI of the walletapplication using which the card details may be entered. The user mayclick a button 416 labeled as ‘Continue’ to submit the selection of‘cards’ as the preferred payment method.

Next, in FIG. 4B, a UI 420 is shown to display a header 422 displayingtext ‘add debit/credit card’. The header 422 is accompanied by aplurality of form fields and a plurality of selectable icons to befilled/selected by the user. The plurality of form fields and theplurality of selectable icons may collectively be referred tohereinafter as a card information 424 of the payment card. The cardinformation 424 includes a name of the cardholder (an example of theform field), a payment card number of the payment card (an example ofthe form field), an expiry date (e.g., MM/YYYY, month and year ofexpiry) (an example of the selectable icon), a CVV number (an example ofthe form field) and the like. A clickable button 426 labeled as ‘pay’ isdisplayed to submit the card information 424 on the merchant application405.

In order to fill the card information 424, the user needs to have accessto the payment card information. Therefore, the user needs to visit thepayment application (e.g., a payment application 442 as explained withreference to a UI 440 hereinafter) to which one or more of his paymentcards are linked. To achieve this, the user may press and hold a homebutton 432 or click a recent button 434 placed on the user device 415 tosee recently opened applications. Recently opened applications are shownby a UI 430 in FIG. 4C. A header 436 displaying text ‘recentapplications’ is shown accompanied by a plurality of applicationsexemplarily displayed as eshop.com 405, payment application 442,etaxi.com 437, and play store 438. The payment application 442 is shownto have selected by the user. The UI 430 further includes a button 439labeled as ‘close all’, which upon being clicked closes all the recentlyvisited applications. In an example embodiment, instead of visitingrecent applications, the user may click the home button 432 on the UI420 and select the payment application icon displayed on a displayscreen of the user device 415 for visiting the payment application.

Next, a UI 440 of the payment application 442 is shown in FIG. 4D todisplay a header 444 displaying text ‘your cards for the linkedmerchants’. Below the header 444, a widget 446 displays eshop.com 405(i.e., a linked merchant) linked to a payment card 448 (shown as endingwith number xxxx xxxx xxxx 5630). Another widget 452 is shown displayingetaxi.com 437 (i.e., another linked merchant) linked to another paymentcard 454 (shown as ending with number xxxx xxxx xxxx 5622). The user isenabled to select eshop.com 405 linked to the payment card 448 byclicking a button 456 labeled as ‘Continue’. Alternatively, the user mayonly need to select a payment card from a list of one or more paymentcards linked to the payment application 442 to initiate the tokenizationprocess of the selected payment card by clicking the button 456.Further, the user is required to authenticate himself by providing abiometric information in order to proceed further. A UI 450 shown inFIG. 4E displays a touch ID exemplarily represented with a biometricicon 458 (e.g., a fingerprint) using which the user can provide inputfor authentication. Alternatively, the biometric authentication can beperformed using face recognition, fingerprint scan, retina scan, irisscan, voice analysis, and the like.

Upon successful authentication, the payment application 442 retrievesthe payment card details of the selected payment card 448 and generatesa tokenization request for sending to the wallet server 155. Asexplained with reference to FIG. 2 , the wallet server 155 is configuredto send the tokenization request to the payment server 140. The paymentserver 140 generates a digital token having replacement tokenizedinformation of the payment card 448 after receiving successfulauthorization notification from the issuer server 135 for thetokenization request. The payment server 140 sends the generated tokento the wallet server 155. The wallet server 155 displays the generateddigital token on a UI via the payment application 442 on the user device415. Accordingly, in FIG. 4F, a UI 460 is shown to display a header 462displaying text ‘your token is ready for use’ accompanied by a token464. The token 464 displays a tokenized card information of the paymentcard 448. This is exemplarily displayed as a tokenized card number being5204 2425 0037 4252, an expiry date being 06/22 for the token 464 and aCVV as 495. The user is required to enter the token 464 on the merchantapplication 405 to process the payment transaction.

In at least one embodiment, after displaying the token 464 on the UI460, the payment application 442 is configured to generate a floatingwidget that includes the token 464 to be displayed on the merchantapplication 405. A clickable button 466 labeled as ‘go to merchant’ isdisplayed, clicking which the user is redirected back to the merchantapplication 405. Alternatively, the user can directly switch back to themerchant application 405 and still a floating widget that includes thetoken 464 can be displayed on the merchant application 405. This isfurther explained by a corresponding UI 470 shown in FIG. 4G.

The UI 470 is same as the UI 420 with an additional floating widget 472that includes the token 464 as generated by the payment application 442.Using the token 464, the user is enabled to enter the card information424. For example, a name of the cardholder is displayed as John smith, apayment card number is displayed as a tokenized card number is displayedas 5204 2425 0037 4252, an expiry date is displayed as 06/22 for thetoken 464 and a CVV is displayed as *** (e.g., 495). A clickable button426 labeled as ‘pay’ is displayed to submit the card information 424 onthe merchant application 405 for processing the payment transaction.

In an example embodiment, the floating widget 472 can be closed by userinteractions on the UI 470 such as by swiping down or by clicking aclose button 474. The floating widget 472 is automatically closed basedon detecting switching of the merchant payment interface (e.g., the UI470) by an application other than the payment application 442 running onthe user device 415. Further, the floating widget 472 is automaticallyclosed based on detecting an inactivity for a predetermined time-period(e.g., 5 minutes) on the merchant payment interface. Screenshot of thefloating widget 472 is disabled. Further, the sensitive information isshowed as an image so that it cannot be copied. In an exampleembodiment, the floating widget 472 can be maximized to full screen tosee the full details. The widget size is not restricted but it is keptminimal enough to show the details clearly. The floating widget 472 canbe moved to any corner of the screen. Further, the secure floatingwidget 472 can be implemented for any screen using applicableApplication Program Interfaces (APIs) supported by various OperatingSystems (OSs, e.g., Android or iOS). Moreover, the floating widget 472can be implemented for various web browsers such as Chrome developed byGoogle, Safari developed by Apple and the like for facilitating webapplication based payment transactions The floating widget 472 can bedisplayed as a horizontal bar with more than one tokens, if the userwishes to use each token for a different merchant application.

As the payment card information 424 is available for the user to enterfrom the floating widget 472, the time taken to enter the informationand the overall time it takes to complete the payment transactionreduces tremendously. Further, as it's a frustration-free checkout, theend-user experience gets enhanced remarkably. Moreover, many times ithappens that synchronization between two applications i.e., the merchantapplication and the payment application get lost during a manual paymentcard entry at the checkout page of the merchant application. Thisfriction point is also resolved by the features of the presentdisclosure as the whole need of hovering between the two applications iseliminated completely by the provision of the digital token on thefloating widget as a ready reference for the submission.

In an example embodiment, while registering by the user at the paymentapplication 440 by adding one or more payment cards for tokenization andusing those tokens for digital transactions using the floating widgets,a UI (not shown) may be displayed by the payment application 442enlisting a plurality of merchants for user selection. The merchant canbe selected by providing one of a merchant name, a merchant applicationor a merchant domain name. The user may select one or more of thepreferred merchants from the list and associate/link one or more of theuploaded payment cards with each selected merchant (e.g., the authorizedmerchant) for future payment transactions. The payment application 442is configured to store this information and later when a preferredmerchant is selected by the user, a floating widget is generated withthe digital token of the linked card for use by the user. This featureprovides extra level security by not letting any random website to havethe token entered using the floating widget.

In one example embodiment, as the payment application 442 already has alist of selected merchants, when the user is at a checkout page of anauthorized merchant's application, the user selects an option for atokenization of the payment card on the merchant's application. The usermay be asked to enter the issuer bank's name after selecting the optionfor the tokenization of the payment card. This triggers tokenization ofthe payment card by the payment application 442 and without the need ofthe user to visit the payment application 442 to provide thetokenization command, the tokenized card information is displayed in afloating widget by the payment application 442 on the check-out page ofthe merchant's application. In an embodiment, the tokenized card isdisplayed in the floating widget post authentication of the user.

Although the disclosure is explained with an example of displaying atokenized payment card information in the floating widget, any sensitiveor critical information where user intervention is required to fill orget the information can be shown in the floating widget withoutdeviation from the scope of the invention. For example, once the tokenis submitted, the user may be directed to a UI (not shown) displayed bya payment getaway (e.g., the payment server 140) to further enter aPIN/a password or a One-time Password (OTP) that is sent by the paymentserver 140 to the user device 415 for user authentication. For accessingthe OTP too, the user needs to switch the applications namely themerchant application and the text message/SMS application on which theOTP is received. In an example embodiment, the network provider APIs canbe utilized by the wallet server 155 such that the payment applicationis able to read the OTP through the SMS and display the same on thepayment gateway UI in a floating widget. Therefore, in addition toproviding the card information in a floating widget during a paymenttransaction, an OTP as well may be provided in a corresponding floatingwidget during the same transaction to assist the user for inputting therespective information.

In one embodiment, the merchant application 405 receives the token 464as the user clicks the button 426 labeled as ‘pay’ on the UI 470, thetoken 464 is sent to the acquirer server 130. The steps 315-375 areprocessed as explained with reference to FIG. 3A for completing thepayment transaction.

FIG. 5 illustrates a flow diagram of a method 500 for enhancing onlinepayment transaction experience, in accordance with an exampleembodiment. More specifically, the method 500 for enabling usage of atokenized payment card in a floating widget for use by a user for makinga payment transaction at an online payment interface is disclosed. Themethod 500 depicted in the flow diagram may be executed by, for example,the at least one server system such as the acquirer server 130, theissuer server 135, the wallet server 155 and the payment server 140explained with reference to FIG. 1 . Operations of the flow diagram 500,and combinations of operation in the flow diagram 500, may beimplemented by, for example, hardware, firmware, a processor, circuitryand/or a different device associated with the execution of software thatincludes one or more computer program instructions. The operations ofthe method 500 are described herein with help of the server systems 130,135, 155 or 140. It is noted that the operations of the method 500 canbe described and/or practiced by using a system other than these serversystems. The method 500 starts at operation 502.

At 502, the method 500 includes receiving, by a server system (e.g., thewallet server 155) associated with a payment network, a tokenizationrequest based on selecting a payment card of a plurality of paymentcards of a user from a payment application running on a user device forprocessing an online payment transaction using the selected payment cardat a merchant payment interface on the user device. The tokenizationrequest at least includes a card information of the selected paymentcard. The wallet server 155 may send the tokenization request to thepayment server 140 over the payment network 145.

At 504, the method 500 includes, facilitating, by the server system, ageneration of a digital token. The digital token includes a tokenizedcard information of the selected payment card. The payment server 140may generate the token based on receiving the tokenization request andsend the token to the wallet server 155.

At 506, the method 500 includes provisioning, by the server system, thedigital token in a floating widget at the merchant payment interface onthe user device. The floating widget enables the user to enter thedigital token at the merchant payment interface for processing theonline payment transaction. The wallet server 155 enables the paymentapplication to generate a floating widget that includes the receivedtoken from the payment server 140 to be displayed on the checkout pageof the merchant application to facilitate completion of the paymenttransaction.

FIG. 6 is a simplified block diagram of a server system 600, inaccordance with one embodiment of the present disclosure. The serversystem 600 is an example of a server system that is a part of thepayment network 145. Examples of the server system 600 includes, but notlimited to, the acquirer server 130, the issuer server 135, the walletserver 155 and the payment server 140. The server system 600 includes acomputer system 605 and a database 610.

The computer system 605 includes at least one processor 615 forexecuting instructions. Instructions may be stored in, for example, butnot limited to, a memory 620. The processor 615 may include one or moreprocessing units (e.g., in a multi-core configuration).

The processor 615 is operatively coupled to a communication interface625 such that the computer system 605 is capable of communicating with aremote device such as a user device 635 (e.g., the user device 115) orcommunicating with any entity within the payment network 145. Forexample, the communication interface 625 may receive the tokenizationrequest from the user device 635, via the Internet.

The processor 615 may also be operatively coupled to the database 610.The database 610 is any computer-operated hardware suitable for storingand/or retrieving data, such as, but not limited to, transaction datagenerated as part of sales activities conducted over the bankcardnetwork including data relating to merchants, account holders orcustomers, and purchases. The database 610 may also store informationrelated to a plurality of user's payment accounts. Each user accountdata includes at least one of a user name, a user address, an accountnumber, PIN, and other account identifiers. The database 610 may alsostore device identifiers and the digital tokens. The database 610 mayalso store a merchant identifier that identifies each merchantregistered to use the payment network, and instructions for settlingtransactions including merchant bank account information (e.g., aplurality of payment accounts related to the merchant interfacesassociated with merchants). The database 610 may further include issueraccount information. The database 610 may also include a list ofmerchants as pre-selected by the user only for each of which the digitaltokens in the floating widgets are to be generated.

The database 610 may include multiple storage units such as hard disksand/or solid-state disks in a redundant array of inexpensive disks(RAID) configuration. The database 610 may include a storage areanetwork (SAN) and/or a network attached storage (NAS) system. In someembodiments, the database 610 is integrated within the computer system605. For example, the computer system 605 may include one or more harddisk drives as the database 610. In other embodiments, the database 610is external to the computer system 605 and may be accessed by thecomputer system 605 using a storage interface 630. The storage interface630 is any component capable of providing the processor 615 with accessto the database 610. The storage interface 630 may include, for example,an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA)adapter, a Small Computer System Interface (SCSI) adapter, a RAIDcontroller, a SAN adapter, a network adapter, and/or any componentproviding the processor 615 with access to the database 610.

The processor 615 is configured to receive a tokenization request viathe communication interface 625. The request is initiated by a userbased on selecting a payment card of a plurality of payment cards of auser from a payment application running on a user device. The processor615 is configured to facilitate generation of a unique digital tokenbased on authorization of the tokenization request received. Theauthorization of the tokenization request may also be performed by theprocessor 615 by validating the tokenization request i.e., a cardinformation of the payment card using the associated card informationstored in the database 610. The processor 615 is configured to send thedigital token to the user device 635 via the communication interface625. The processor is configured to provision the digital token in afloating widget at a merchant payment interface on the user device 635.The floating widget enables the user to enter the digital token at themerchant payment interface for processing the online paymenttransaction.

FIG. 7 is a simplified block diagram of a wallet server 700, inaccordance with one embodiment of the present disclosure. The walletserver 700 is an example of third-party wallet application configured toprovide its registered users storage of their payment cards on digitalplatform so as to make card-less payments. The wallet server 700 is anexample of the wallet server 155 of FIG. 1 . The wallet server 700includes at least one processing module 705 communicably coupled to acommunication interface 710 and at least one memory 715. In at least oneembodiment, the wallet server 700 may be accessible to remote devices,such as a remote device 725, through a communication network, such asthe network 150 or the payment network 145.

The processing module 705 is capable of executing the stored machineexecutable instructions of a payment application 720 (e.g., the paymentapplication 442) in the memory 715 or within the processing module 705or any storage location accessible to the processing module 705. Theprocessing module 705 is configured to perform the various operations asexplained with reference to method 500. For example, the processingmodule 705 is configured to receive the tokenization request from a userdevice of a user via the communication interface 710 and forward it tothe payment server 140 for the tokenization of the payment card selectedby the user. The processing module 705 is configured to store the cardinformation of the payment card for facilitating the user to makedigital payment transactions using the stored card information. Theprocessing module 705, in conjunction with, the payment application 720is configured to generate a floating widget that can be displayed on acheckout page of the merchant application. The floating widget includesthe tokenized card information. The processing module 705 is configuredto close the floating widget based on detecting an inactivity for apredetermined time-period on the merchant payment interface. Further,the processing module 705 is configured close the floating widget basedon detecting switching of the merchant payment interface by anapplication other than the payment application running on the userdevice.

In an embodiment, the processing module 705 may be embodied as one ormore of various processing devices, such as a coprocessor, amicroprocessor, a controller, a digital signal processor (DSP),processing circuitry with or without an accompanying DSP, or variousother processing devices including integrated circuits such as, forexample, an application specific integrated circuit (ASIC), a fieldprogrammable gate array (FPGA), a microcontroller unit (MCU), a hardwareaccelerator, a special-purpose computer chip, or the like.

The memory 715 can be any type of storage accessible to the processingmodule 705. The memory 715 includes program instructions forfacilitating the payment application 720. For example, the memory 715may include volatile or non-volatile memories, or a combination thereof.In some non-limiting examples, the memory 715 can be four to sixty-fourMegabytes (MB) of Dynamic Random Access Memory (“DRAM”) or Static RandomAccess Memory (“SRAM”). In addition, some examples may includesupplementary flash memory installed via a PCMCIA slot.

The communication interface 710 is further configured to cause displayof user interfaces on the remote device 725. In one embodiment, thecommunication interface 710 includes a transceiver for wirelesslycommunicating information to, or receiving information from, the remotedevice 725 or other suitable display device, and/or another type ofremote processing device. In another embodiment, the communicationinterface 710 is capable of facilitating operative communication withthe remote devices and a cloud server using Application ProgramInterface (API) calls. The communication may be achieved over acommunication network, such as the network 150.

FIG. 8 is a simplified block diagram of an issuer server 800, inaccordance with one embodiment of the present disclosure. The issuerserver 800 is an example of the issuer server 135 of FIG. 1 or may beembodied in the issuer server 135. The issuer server 800 is associatedwith an issuer bank/issuer, in which a user may have an account. Theissuer server 800 includes a processing module 805 operatively coupledto a storage module 810, an authorization module 815, and acommunication module 820. The components of the issuer server 800provided herein may not be exhaustive, and that the issuer server 800may include more or fewer components than that of depicted in FIG. 8 .Further, two or more components may be embodied in one single component,and/or one component may be configured using multiple sub-components toachieve the desired functionalities. Some components of the issuerserver 800 may be configured using hardware elements, software elements,firmware elements and/or a combination thereof.

The storage module 810 is configured to store machine executableinstructions to be accessed by the processing module 805. Additionally,the storage module 810 stores information related to, contactinformation of the user, identification information of the user, bankaccount number, BICs, payment card details, internet bankinginformation, PIN, mobile personal identification number (MPIN) formobile banking and the like. The PIN is a four-digit identification codeissued by the issuer bank of the user while registering for electronicpayment transactions or while issuing the payment card to the user. Forexample, the PIN may be issued for swipe based transactions, mobilebanking, internet banking, payment string based transaction and thelike. The PIN is needed to be verified for authentication of the user'sidentity and association with the issuer bank to process the paymenttransaction. This information is retrieved by the processing module 805for cross-verification during payment transactions.

The processing module 805, in conjunction with the authorization module815, is configured to validate the card information received from thepayment server 140 via the communication module 820. Additionally, theprocessing module 805 is configured to verify the PIN, the sufficientfunds in the issuer account and the like. Upon successful authorizationof the card information and the cardholder only, the payment transactionis processed further by the processing module 805 by debiting thetransaction amount from the issuer account of the user. The processingmodule 805 is further configured to communicate with one or more remotedevices such as a remote device 825 using the communication module 820over a network such as the network 150 or the payment network 145 ofFIG. 1 . The examples of the remote device 825 include, the user device635, the payment server 140, the acquirer server 130, the wallet server700, other computing systems of issuer and the payment network 145 andthe like. The communication module 820 is capable of facilitating suchoperative communication with the remote devices and cloud servers usingAPI (Application Program Interface) calls.

FIG. 9 is a simplified block diagram of an acquirer server 900, inaccordance with one embodiment of the present disclosure. The acquirerserver 900 is associated with the acquirer bank of a merchant where themerchant has established an account to accept payment using the digitaltoken. The acquirer server 900 is an example of the acquirer server 130of FIG. 1 or may be embodied in the acquirer server 130. Further, theacquirer server 900 is configured to facilitate the digital token basedpayment transaction with the issuer server 800 using the payment network145 of FIG. 1 . The acquirer server 900 includes a processing module 905communicably coupled to a merchant database 910 and a communicationmodule 915. The components of the acquirer server 900 provided hereinmay not be exhaustive, and that the acquirer server 900 may include moreor fewer components than that of depicted in FIG. 9 . Further, two ormore components may be embodied in one single component, and/or onecomponent may be configured using multiple sub-components to achieve thedesired functionalities. Some components of the acquirer server 900 maybe configured using hardware elements, software elements, firmwareelements and/or a combination thereof.

The merchant database 910 includes data related to a merchant, such as,but not limited to, a merchant primary account number (PAN), a merchantname, a merchant category code (MCC), a merchant city, a merchant postalcode, a merchant brand name, a merchant ID and the like. The processingmodule 905 is configured to use the merchant ID to identify the merchantduring the normal processing of payment transactions, adjustments,chargebacks, end-of-month fees and so forth. The merchant ID isdifferent than other merchant account numbers, particularly those thatidentify merchants to the equipment (e.g., the POS terminals or anyother merchant electronic devices) they use for processing transactions.A merchant with a single merchant processing account number may useseveral terminals at one location, resulting in one merchant ID andseveral terminal identification numbers (TIDs). The processing module905 may be configured to store and update such merchant information inthe merchant database 910 for later retrieval.

In an embodiment, the communication module 915 is capable offacilitating operative communication with a remote device 920 (e.g., theissuer server 800, the wallet server 700 and/or the payment server 140)using API calls. The communication may be achieved over a communicationnetwork, such as the network 150. For example, the processing module 905may receive the token and the transaction amount from the merchantinterface (e.g., an e-commerce website) using the communication module915. Further, the processing module 905 is configured to receive thedebited transaction amount from the payment server 140 or the issuerserver 135 (or the issuer server 800) using the communication module915. Thereafter, the processing module 905 may retrieve merchant PANfrom the merchant database 910 to credit the transaction amount in theacquirer account of the merchant. Further, the processing module 905 maybe configured to send the transaction status to the merchant device ofthe merchant and the user device 635.

FIG. 10 is a simplified block diagram of a payment server 1000 used fordesignated payment transaction, in accordance with one embodiment of thepresent disclosure. The payment server 1000 may correspond to thepayment server 140 of FIG. 1 . As explained with reference to FIG. 1 ,the payment server 140 is associated with a payment network 145. Thepayment network 145 may be used by the wallet server 700, the issuerserver 800 and the acquirer server 900 as a payment interchange network.Examples of the payment interchange network include, but not limited to,Mastercard® payment system interchange network. The payment server 1000includes a processing system 1005 configured to extract programminginstructions from a memory 1010 to provide various features of thepresent disclosure. The components of the payment server 1000 providedherein may not be exhaustive, and that the payment server 1000 mayinclude more or fewer components than that of depicted in FIG. 10 .Further, two or more components may be embodied in one single component,and/or one component may be configured using multiple sub-components toachieve the desired functionalities. Some components of the paymentserver 1000 may be configured using hardware elements, softwareelements, firmware elements and/or a combination thereof.

Via a communication interface 1020, the processing system 1005 receivesa tokenization request from a remote device 1035, such as the walletserver 700. The communication may be achieved through API calls, withoutloss of generality. A token generation module 1025 is operativelycoupled to the processing system 1005. The token generation module 1025includes one or more algorithms capable of generating the token.Further, a token validation module 1030 that may include a predefinedrule set to be used for validation of the token received at the time ofpayment transaction. The token may be received from a remote entity,such as the acquirer server 900 via the communication interface 1020.The validation of the token is performed based on mapping the token withthe associated PAN of the user as stored in a database 1015. Thedatabase 1015 may also store PIN, the transaction amount, acquireraccount information, transaction records, merchant account information,and the like. Apart from the token generation and validation, theprocessing system 1005 may be configured to perform various functionssuch as maintenance and operation of the database 1015, token issuanceand token provisioning, token domain restriction controls (e.g., thesame token may be used for a Mobile NFC at Point of Sale transaction andalso used in another transaction at an e-commerce website), tokenrequestor IDs generation and the like.

FIG. 11 shows simplified block diagram of a user device 1100 for examplea mobile phone or a desktop computer capable of implementing the variousembodiments of the present disclosure. For example, the user device 1100may correspond to the user device 635 (e.g., the user device 115 of FIG.1 ) of FIG. 6 . The user device 1100 is depicted to include one or moreapplications, such as a payment application and a merchant application.The payment application can be an instance of an application downloadedfrom any of the servers 130, 135, 155 and 140. The payment application1106 is capable of communicating with any of the servers 130, 135, 155and 140 and the merchant payment interface 302 for facilitating adigital token in a floating widget on the merchant payment interface 302for completing payment transactions using the tokenization of thepayment card.

It should be understood that the user device 1100 as illustrated andhereinafter described is merely illustrative of one type of device andshould not be taken to limit the scope of the embodiments. As such, itshould be appreciated that at least some of the components describedbelow in connection with that the user device 1100 may be optional andthus in an example embodiment may include more, less or differentcomponents than those described in connection with the exampleembodiment of the FIG. 11 . As such, among other examples, the userdevice 1100 could be any of a mobile electronic device, for example,cellular phones, tablet computers, laptops, mobile computers, personaldigital assistants (PDAs), mobile televisions, mobile digitalassistants, or any combination of the aforementioned, and other types ofcommunication or multimedia devices.

The illustrated user device 1100 includes a controller or a processor1102 (e.g., a signal processor, microprocessor, ASIC, or other controland processing logic circuitry) for performing such tasks as signalcoding, data processing, image processing, input/output processing,power control, and/or other functions. An operating system 1104 controlsthe allocation and usage of the components of the user device 1100 andsupport for one or more payment transaction applications programs (see,the applications 1106) such as the payment application, that implementsone or more of the innovative features described herein. In addition,the payment application, the applications 1106 may include merchantapplication, common mobile computing applications (e.g., telephonyapplications, email applications, calendars, contact managers, webbrowsers, messaging applications) or any other computing application.

The illustrated user device 1100 includes one or more memory components,for example, a non-removable memory 1108 and/or removable memory 1110.The non-removable memory 1108 and/or the removable memory 1110 may becollectively known as a database in an embodiment. The non-removablememory 1108 can include RAM, ROM, flash memory, a hard disk, or otherwell-known memory storage technologies. The removable memory 1110 caninclude flash memory, smart cards, or a Subscriber Identity Module(SIM). The one or more memory components can be used for storing dataand/or code for running the operating system 1104 and the applications1106. The user device 1100 may further include a user identity module(UIM) 1112. The UIM 1112 may be a memory device having a processor builtin. The UIM 1112 may include, for example, a subscriber identity module(SIM), a universal integrated circuit card (UICC), a universalsubscriber identity module (USIM), a removable user identity module(R-UIM), or any other smart card. The UIM 1112 typically storesinformation elements related to a mobile subscriber. The UIM 1112 inform of the SIM card is well known in Global System for MobileCommunications (GSM) communication systems, Code Division MultipleAccess (CDMA) systems, or with third-generation (3G) wirelesscommunication protocols such as Universal Mobile TelecommunicationsSystem (UMTS), CDMA9000, wideband CDMA (WCDMA) and timedivision-synchronous CDMA (TD-SCDMA), or with fourth-generation (4G)wireless communication protocols such as LTE (Long-Term Evolution).

The user device 1100 can support one or more input devices 1120 and oneor more output devices 1130. Examples of the input devices 1120 mayinclude, but are not limited to, a touch screen/a display screen 1122(e.g., capable of capturing finger tap inputs, finger gesture inputs,multi-finger tap inputs, multi-finger gesture inputs, or keystrokeinputs from a virtual keyboard or keypad), a microphone 1124 (e.g.,capable of capturing voice input), a camera module 1126 (e.g., capableof capturing still picture images and/or video images) and a physicalkeyboard 1128. Examples of the output devices 1130 may include, but arenot limited to a speaker 1132 and a display 1134. Other possible outputdevices can include piezoelectric or other haptic output devices. Somedevices can serve more than one input/output function. For example, thetouch screen 1122 and the display 1134 can be combined into a singleinput/output device.

A wireless modem 1140 can be coupled to one or more antennas (not shownin the FIG. 11 ) and can support two-way communications between theprocessor 1102 and external devices, as is well understood in the art.The wireless modem 1140 is shown generically and can include, forexample, a cellular modem 1142 for communicating at long range with themobile communication network, a Wi-Fi compatible modem 1144 forcommunicating at short range with an external Bluetooth-equipped deviceor a local wireless data network or router, and/or aBluetooth-compatible modem 1146. The wireless modem 1140 is typicallyconfigured for communication with one or more cellular networks, such asa GSM network for data and voice communications within a single cellularnetwork, between cellular networks, or between the user device 1100 anda public switched telephone network (PSTN).

The user device 1100 can further include one or more input/output ports1150, a power supply 1152, one or more sensors 1154 for example, anaccelerometer, a gyroscope, a compass, or an infrared proximity sensorfor detecting the orientation or motion of the user device 1100 andbiometric sensors for scanning biometric identity of an authorized user,a transceiver 1156 (for wirelessly transmitting analog or digitalsignals) and/or a physical connector 1160, which can be a USB port, IEEE1294 (FireWire) port, and/or RS-232 port. The illustrated components arenot required or all-inclusive, as any of the components shown can bedeleted and other components can be added.

The disclosed method with reference to FIG. 5 , or one or moreoperations of the flow diagram 500 may be implemented using softwareincluding computer-executable instructions stored on one or morecomputer-readable media (e.g., non-transitory computer-readable media,such as one or more optical media discs, volatile memory components(e.g., DRAM or SRAM), or non-volatile memory or storage components(e.g., hard drives or solid-state non-volatile memory components, suchas Flash memory components) and executed on a computer (e.g., anysuitable computer, such as a laptop computer, net book, Web book, tabletcomputing device, smart phone, or other mobile computing device). Suchsoftware may be executed, for example, on a single local computer or ina network environment (e.g., via the Internet, a wide-area network, alocal-area network, a remote web-based server, a client-server network(such as a cloud computing network), or other such network) using one ormore network computers. Additionally, any of the intermediate or finaldata created and used during implementation of the disclosed methods orsystems may also be stored on one or more computer-readable media (e.g.,non-transitory computer-readable media) and are considered to be withinthe scope of the disclosed technology. Furthermore, any of thesoftware-based embodiments may be uploaded, downloaded, or remotelyaccessed through a suitable communication means. Such suitablecommunication means include, for example, the Internet, the World WideWeb, an intranet, software applications, cable (including fiber opticcable), magnetic communications, electromagnetic communications(including RF, microwave, and infrared communications), electroniccommunications, or other such communication means.

Although the invention has been described with reference to specificexemplary embodiments, it is noted that various modifications andchanges may be made to these embodiments without departing from thebroad spirit and scope of the invention. For example, the variousoperations, blocks, etc., described herein may be enabled and operatedusing hardware circuitry (for example, complementary metal oxidesemiconductor (CMOS) based logic circuitry), firmware, software and/orany combination of hardware, firmware, and/or software (for example,embodied in a machine-readable medium). For example, the apparatuses andmethods may be embodied using transistors, logic gates, and electricalcircuits (for example, application specific integrated circuit (ASIC)circuitry and/or in Digital Signal Processor (DSP) circuitry).

Particularly, the server systems 130, 135, 155 and 140 its variouscomponents such as the computer system 605 and the database 610 may beenabled using software and/or using transistors, logic gates, andelectrical circuits (for example, integrated circuit circuitry such asASIC circuitry). Various embodiments of the invention may include one ormore computer programs stored or otherwise embodied on acomputer-readable medium, wherein the computer programs are configuredto cause a processor or computer to perform one or more operations. Acomputer-readable medium storing, embodying, or encoded with a computerprogram, or similar language, may be embodied as a tangible data storagedevice storing one or more software programs that are configured tocause a processor or computer to perform one or more operations. Suchoperations may be, for example, any of the steps or operations describedherein. In some embodiments, the computer programs may be stored andprovided to a computer using any type of non-transitory computerreadable media. Non-transitory computer readable media include any typeof tangible storage media. Examples of non-transitory computer readablemedia include magnetic storage media (such as floppy disks, magnetictapes, hard disk drives, etc.), optical magnetic storage media (e.g.magneto-optical disks), CD-ROM (compact disc read only memory), CD-R(compact disc recordable), CD-R/W (compact disc rewritable), DVD(Digital Versatile Disc), BD (BLU-RAY® Disc), and semiconductor memories(such as mask ROM, PROM (programmable ROM), EPROM (erasable PROM), flashmemory, RAM (random access memory), etc.). Additionally, a tangible datastorage device may be embodied as one or more volatile memory devices,one or more non-volatile memory devices, and/or a combination of one ormore volatile memory devices and non-volatile memory devices. In someembodiments, the computer programs may be provided to a computer usingany type of transitory computer readable media. Examples of transitorycomputer readable media include electric signals, optical signals, andelectromagnetic waves. Transitory computer readable media can providethe program to a computer via a wired communication line (e.g. electricwires, and optical fibers) or a wireless communication line.

Various embodiments of the invention, as discussed above, may bepracticed with steps and/or operations in a different order, and/or withhardware elements in configurations, which are different than thosewhich, are disclosed. Therefore, although the invention has beendescribed based upon these exemplary embodiments, it is noted thatcertain modifications, variations, and alternative constructions may beapparent and well within the spirit and scope of the invention.

Although various exemplary embodiments of the invention are describedherein in a language specific to structural features and/ormethodological acts, the subject matter defined in the appended claimsis not necessarily limited to the specific features or acts describedabove. Rather, the specific features and acts described above aredisclosed as exemplary forms of implementing the claims.

What is claimed is:
 1. A computer program product comprising at leastone non-transitory computer-readable storage medium, thecomputer-readable storage medium comprising a set of instructions which,when executed by one or more processors in a user device, cause the userdevice to perform operations comprising: presenting, via a paymentapplication running on the user device, an interactive user interface;sending, to a server, a tokenization request based on a selected apayment card of a user for processing an online payment transactionusing the selected payment card at a merchant payment interface on theuser device, wherein the tokenization request at least comprises a cardinformation of the selected payment card; receiving, from the server, adigital token comprising a tokenized card information of the selectedpayment card; and displaying, via the interactive user interface, thedigital token as an image in a floating widget, wherein the floatingwidget remains visible after switching to a merchant payment interfaceand enables the user to manually enter the digital token at the merchantpayment interface for processing the online payment transaction; whereina screenshot of the floating widget is disabled while the token as animage is displayed to prevent copying of the token; and wherein thefloating widget is automatically closed based on one or more ofdetecting an inactivity for a predetermined time-period on the merchantpayment interface or detecting switching of the merchant paymentinterface by an application other than the payment application runningon the user device.
 2. The computer program product of claim 1, whereinthe instructions, when executed, cause the user device to performfurther operations comprising: receiving one of a PersonalIdentification Number (PIN), a password or a One-time Password (OTP);and displaying, via the interactive user interface, the one of the PIN,the password or the OTP in the floating widget, wherein the floatingwidget enables the user to enter the one of the PIN, the password or theOTP at the merchant payment interface for processing the online paymenttransaction.
 3. The computer program product of claim 2, wherein the OTPis received via an SMS application reading an SMS message containing theOTP.
 4. The computer program product of claim 1, wherein theinstructions, when executed, cause the user device to perform furtheroperations comprising: obtaining, via the interactive user interface, abiometric input from the user for authentication of the user; whereinthe biometric input includes one or more of a facial scan, a fingerprintscan, a retina scan, an iris scan, or a voice input.
 5. The computerprogram product of claim 1, wherein the instructions, when executed,cause the user device to perform further operations comprising:displaying a pre-defined list of merchants for user selection via theinteractive user interface; receiving a user selection of one or moremerchants from the pre-defined list of the merchants; and linking atleast one payment card of one or more of payment cards of the user witheach of the one or more user selected merchants.
 6. The computer programproduct of claim 5, wherein the instructions, when executed, cause theuser device to perform further operations comprising: sending, to theserver, a request to initiate tokenization of a pre-linked payment cardfrom a user selected merchant of the one or more user selectedmerchants, the request generated based on a user selection of a tokenbased payment from the merchant payment interface; and displaying, viathe interactive user interface, the digital token in the floating widgetat the merchant payment interface on the user device, wherein thefloating widget enables the user to enter the digital token at themerchant payment interface for processing the online paymenttransaction.
 7. The computer program product of claim 6, wherein thefloating widget is displayed as a horizontal bar to include a pluralityof digital tokens, each digital token for a different one of the one ormore user selected merchants.
 8. The computer program product of claim1, wherein the floating widget is sized to fit the contents of thedigital token, and wherein the floating widget is relocatable within adisplay screen of the user device.
 9. A computer implemented methodcomprising: presenting, via a payment application running on a userdevice, an interactive user interface; sending, to a server, atokenization request based on a selected a payment card of a user forprocessing an online payment transaction using the selected payment cardat a merchant payment interface on the user device, wherein thetokenization request at least comprises a card information of theselected payment card; receiving, from the server, a digital tokencomprising a tokenized card information of the selected payment card;and displaying, via the interactive user interface, the digital token asan image in a floating widget, wherein the floating widget remainsvisible after switching to a merchant payment interface and enables theuser to manually enter the digital token at the merchant paymentinterface for processing the online payment transaction; wherein ascreenshot of the floating widget is disabled while the token as animage is displayed to prevent copying of the token; and wherein thefloating widget is automatically closed based on one or more ofdetecting an inactivity for a predetermined time-period on the merchantpayment interface or detecting switching of the merchant paymentinterface by an application other than the payment application runningon the user device.
 10. The method of claim 9, further comprising:receiving one of a Personal Identification Number (PIN), a password or aOne-time Password (OTP); and displaying, via the interactive userinterface, the one of the PIN, the password or the OTP in the floatingwidget, wherein the floating widget enables the user to enter the one ofthe PIN, the password or the OTP at the merchant payment interface forprocessing the online payment transaction.
 11. The method of claim 10,wherein the OTP is received via an SMS application reading an SMSmessage containing the OTP.
 12. The method of claim 9, furthercomprising: obtaining, via the interactive user interface, a biometricinput from the user for authentication of the user; wherein thebiometric input includes one or more of a facial scan, a fingerprintscan, a retina scan, an iris scan, or a voice input.
 13. The method ofclaim 9, further comprising: displaying a pre-defined list of merchantsfor user selection via the interactive user interface; receiving a userselection of one or more merchants from the pre-defined list of themerchants; and linking at least one payment card of one or more ofpayment cards of the user with each of the one or more user selectedmerchants.
 14. The method of claim 13, further comprising: sending, tothe server, a request to initiate tokenization of a pre-linked paymentcard from a user selected merchant of the one or more user selectedmerchants, the request generated based on a user selection of a tokenbased payment from the merchant payment interface; and displaying, viathe interactive user interface, the digital token in the floating widgetat the merchant payment interface on the user device, wherein thefloating widget enables the user to enter the digital token at themerchant payment interface for processing the online paymenttransaction.
 15. The method of claim 14, wherein the floating widget isdisplayed as a horizontal bar to include a plurality of digital tokens,each digital token for a different one of the one or more user selectedmerchants.
 16. The method of claim 9, wherein the floating widget issized to fit the contents of the digital token, and wherein the floatingwidget is relocatable within a display screen of the user device.
 17. Acomputing device comprising: a processor; and a memory coupled to theprocessor, the memory storing instructions which, when executed by theprocessor, cause the computing device to perform operations comprising:presenting, via a payment application running on the computing device,an interactive user interface; sending, to a server, a tokenizationrequest based on a selected a payment card of a user for processing anonline payment transaction using the selected payment card at a merchantpayment interface on the computing device, wherein the tokenizationrequest at least comprises a card information of the selected paymentcard; receiving, from the server, a digital token comprising a tokenizedcard information of the selected payment card; and displaying, via theinteractive user interface, the digital token as an image in a floatingwidget, wherein the floating widget remains visible after switching to amerchant payment interface and enables the user to manually enter thedigital token at the merchant payment interface for processing theonline payment transaction; wherein a screenshot of the floating widgetis disabled while the token as an image is displayed to prevent copyingof the token; and wherein the floating widget is automatically closedbased on one or more of detecting an inactivity for a predeterminedtime-period on the merchant payment interface or detecting switching ofthe merchant payment interface by an application other than the paymentapplication running on the computing device.
 18. The computing device ofclaim 17, wherein the instructions, when executed, cause the computingdevice to perform further operations comprising: receiving one of aPersonal Identification Number (PIN), a password or a One-time Password(OTP); and displaying, via the interactive user interface, the one ofthe PIN, the password or the OTP in the floating widget, wherein thefloating widget enables the user to enter the one of the PIN, thepassword or the OTP at the merchant payment interface for processing theonline payment transaction; wherein the OTP is received via an SMSapplication reading an SMS message containing the OTP.
 19. The computingdevice of claim 17, wherein the instructions, when executed, cause thecomputing device to perform further operations comprising: obtaining,via the interactive user interface, a biometric input from the user forauthentication of the user; wherein the biometric input includes one ormore of a facial scan, a fingerprint scan, a retina scan, an iris scan,or a voice input.
 20. The computing device of claim 17, wherein theinstructions, when executed, cause the computing device to performfurther operations comprising: displaying a pre-defined list ofmerchants for user selection via the interactive user interface;receiving a user selection of one or more merchants from the pre-definedlist of the merchants; linking at least one payment card of one or moreof payment cards of the user with each of the one or more user selectedmerchants; sending, to the server, a request to initiate tokenization ofa pre-linked payment card from a user selected merchant of the one ormore user selected merchants, the request generated based on a userselection of a token based payment from the merchant payment interface;and displaying, via the interactive user interface, the digital token inthe floating widget at the merchant payment interface on the userdevice, wherein the floating widget enables the user to enter thedigital token at the merchant payment interface for processing theonline payment transaction; wherein the floating widget is displayed asa horizontal bar to include a plurality of digital tokens, each digitaltoken for a different one of the one or more user selected merchants.